<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
<html lang="en"><head><title>Draft: Email Address to URL Transformation 1.0 - Draft 4</title>
<meta http-equiv="Expires" content="Sun, 29 Jun 2008 21:21:31 +0000">
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta name="description" content="Email Address to URL Transformation 1.0 - Draft 4">
<meta name="generator" content="xml2rfc v1.33 (http://xml.resource.org/)">
<style type='text/css'><!--
        body {
                font-family: verdana, charcoal, helvetica, arial, sans-serif;
                font-size: small; color: #000; background-color: #FFF;
                margin: 2em;
        }
        h1, h2, h3, h4, h5, h6 {
                font-family: helvetica, monaco, "MS Sans Serif", arial, sans-serif;
                font-weight: bold; font-style: normal;
        }
        h1 { color: #900; background-color: transparent; text-align: right; }
        h3 { color: #333; background-color: transparent; }

        td.RFCbug {
                font-size: x-small; text-decoration: none;
                width: 30px; height: 30px; padding-top: 2px;
                text-align: justify; vertical-align: middle;
                background-color: #000;
        }
        td.RFCbug span.RFC {
                font-family: monaco, charcoal, geneva, "MS Sans Serif", helvetica, verdana, sans-serif;
                font-weight: bold; color: #666;
        }
        td.RFCbug span.hotText {
                font-family: charcoal, monaco, geneva, "MS Sans Serif", helvetica, verdana, sans-serif;
                font-weight: normal; text-align: center; color: #FFF;
        }

        table.TOCbug { width: 30px; height: 15px; }
        td.TOCbug {
                text-align: center; width: 30px; height: 15px;
                color: #FFF; background-color: #900;
        }
        td.TOCbug a {
                font-family: monaco, charcoal, geneva, "MS Sans Serif", helvetica, sans-serif;
                font-weight: bold; font-size: x-small; text-decoration: none;
                color: #FFF; background-color: transparent;
        }

        td.header {
                font-family: arial, helvetica, sans-serif; font-size: x-small;
                vertical-align: top; width: 33%;
                color: #FFF; background-color: #666;
        }
        td.author { font-weight: bold; font-size: x-small; margin-left: 4em; }
        td.author-text { font-size: x-small; }

        /* info code from SantaKlauss at http://www.madaboutstyle.com/tooltip2.html */
        a.info {
                /* This is the key. */
                position: relative;
                z-index: 24;
                text-decoration: none;
        }
        a.info:hover {
                z-index: 25;
                color: #FFF; background-color: #900;
        }
        a.info span { display: none; }
        a.info:hover span.info {
                /* The span will display just on :hover state. */
                display: block;
                position: absolute;
                font-size: smaller;
                top: 2em; left: -5em; width: 15em;
                padding: 2px; border: 1px solid #333;
                color: #900; background-color: #EEE;
                text-align: left;
        }

        a { font-weight: bold; }
        a:link    { color: #900; background-color: transparent; }
        a:visited { color: #633; background-color: transparent; }
        a:active  { color: #633; background-color: transparent; }

        p { margin-left: 2em; margin-right: 2em; }
        p.copyright { font-size: x-small; }
        p.toc { font-size: small; font-weight: bold; margin-left: 3em; }
        table.toc { margin: 0 0 0 3em; padding: 0; border: 0; vertical-align: text-top; }
        td.toc { font-size: small; font-weight: bold; vertical-align: text-top; }

        ol.text { margin-left: 2em; margin-right: 2em; }
        ul.text { margin-left: 2em; margin-right: 2em; }
        li      { margin-left: 3em; }

        /* RFC-2629 <spanx>s and <artwork>s. */
        em     { font-style: italic; }
        strong { font-weight: bold; }
        dfn    { font-weight: bold; font-style: normal; }
        cite   { font-weight: normal; font-style: normal; }
        tt     { color: #036; }
        tt, pre, pre dfn, pre em, pre cite, pre span {
                font-family: "Courier New", Courier, monospace; font-size: small;
        }
        pre {
                text-align: left; padding: 4px;
                color: #000; background-color: #CCC;
        }
        pre dfn  { color: #900; }
        pre em   { color: #66F; background-color: #FFC; font-weight: normal; }
        pre .key { color: #33C; font-weight: bold; }
        pre .id  { color: #900; }
        pre .str { color: #000; background-color: #CFF; }
        pre .val { color: #066; }
        pre .rep { color: #909; }
        pre .oth { color: #000; background-color: #FCF; }
        pre .err { background-color: #FCC; }

        /* RFC-2629 <texttable>s. */
        table.all, table.full, table.headers, table.none {
                font-size: small; text-align: center; border-width: 2px;
                vertical-align: top; border-collapse: collapse;
        }
        table.all, table.full { border-style: solid; border-color: black; }
        table.headers, table.none { border-style: none; }
        th {
                font-weight: bold; border-color: black;
                border-width: 2px 2px 3px 2px;
        }
        table.all th, table.full th { border-style: solid; }
        table.headers th { border-style: none none solid none; }
        table.none th { border-style: none; }
        table.all td {
                border-style: solid; border-color: #333;
                border-width: 1px 2px;
        }
        table.full td, table.headers td, table.none td { border-style: none; }

        hr { height: 1px; }
        hr.insert {
                width: 80%; border-style: none; border-width: 0;
                color: #CCC; background-color: #CCC;
        }
--></style>
</head>
<body>
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td></tr></table>
<table summary="layout" width="66%" border="0" cellpadding="0" cellspacing="0"><tr><td><table summary="layout" width="100%" border="0" cellpadding="2" cellspacing="1">
<tr><td class="header">Draft</td><td class="header">D. Fuelling</td></tr>
<tr><td class="header">&nbsp;</td><td class="header">Sappenin Technologies</td></tr>
<tr><td class="header">&nbsp;</td><td class="header">W. Norris</td></tr>
<tr><td class="header">&nbsp;</td><td class="header">Vidoop</td></tr>
<tr><td class="header">&nbsp;</td><td class="header">June 29, 2008</td></tr>
</table></td></tr></table>
<h1><br />Email Address to URL Transformation 1.0 - Draft 4</h1>

<h3>Abstract</h3>

<p>
				Email Address to URL Transformation (EAUT) defines a
				mechanism for transforming the "addr-spec" portion of an
				RFC2822 email address into an associated URL. The
				transform options outlined in this document are designed
				to be flexible enough such that every DNS domain-owner
				can specify unlimited email address to URL
				transformations that services can easily discover and
				utilize in their URL-based transactions.
			
</p>
<h3>Editorial Note</h3>

<p>
				To provide feedback on this draft, join the Google
				Groups discussion list at
				<a href='http://groups.google.com/group/email-address-to-openid'>http://groups.google.com/group/email-address-to-openid</a>
				. For more general information about this protocol,
				please consult
				<a href='http://www.eaut.org'>http://www.eaut.org</a>
				.
			
</p><a name="toc"></a><br /><hr />
<h3>Table of Contents</h3>
<p class="toc">
<a href="#anchor1">1.</a>&nbsp;
Requirements Notation<br />
<a href="#terminology">2.</a>&nbsp;
Terminology<br />
<a href="#anchor2">3.</a>&nbsp;
Protocol Overview <br />
<a href="#discovery">4.</a>&nbsp;
EAUT Discovery<br />
&nbsp;&nbsp;&nbsp;&nbsp;<a href="#obtaining-discovery-endpoint">4.1.</a>&nbsp;
Determining the EAUT Discovery Endpoint URL<br />
&nbsp;&nbsp;&nbsp;&nbsp;<a href="#discovered_info">4.2.</a>&nbsp;
Discovered Information<br />
&nbsp;&nbsp;&nbsp;&nbsp;<a href="#anchor3">4.3.</a>&nbsp;
XRDS-Based Discovery<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<a href="#valid_service_type_elements">4.3.1.</a>&nbsp;
Valid Service Type Elements<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<a href="#extracting_auth">4.3.2.</a>&nbsp;
Extracting the EAUT Template or EAUT Mapping Service Endpoint URL<br />
<a href="#eaut_template_transformation">5.</a>&nbsp;
Transforming an Email Address using an EAUT Template<br />
&nbsp;&nbsp;&nbsp;&nbsp;<a href="#eaut_template_structure">5.1.</a>&nbsp;
EAUT Template Structure<br />
&nbsp;&nbsp;&nbsp;&nbsp;<a href="#eaut_template_validity">5.2.</a>&nbsp;
EAUT Template Validity<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<a href="#valid_eaut_template">5.2.1.</a>&nbsp;
Valid EAUT Template<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<a href="#invalid_eaut_template">5.2.2.</a>&nbsp;
Invalid EAUT Template<br />
&nbsp;&nbsp;&nbsp;&nbsp;<a href="#eaut_template_transform_procedure">5.3.</a>&nbsp;
EAUT Template Transform Procedure<br />
<a href="#eaut_mapping_transformation">6.</a>&nbsp;
Transforming an Email Identifier using an EAUT Mapping Service<br />
&nbsp;&nbsp;&nbsp;&nbsp;<a href="#eaut_mapping_service_query">6.1.</a>&nbsp;
EAUT Mapping Service Query<br />
&nbsp;&nbsp;&nbsp;&nbsp;<a href="#eaut_mapping_service_result">6.2.</a>&nbsp;
EAUT Mapping Service Result<br />
<a href="#anchor6">7.</a>&nbsp;
Security Considerations<br />
&nbsp;&nbsp;&nbsp;&nbsp;<a href="#anchor7">7.1.</a>&nbsp;
Man-in-the-Middle Attacks<br />
&nbsp;&nbsp;&nbsp;&nbsp;<a href="#eaut_mapping_service_email_address_harvesting_attack">7.2.</a>&nbsp;
EAUT Mapping Email-Address Harvesting Attack<br />
&nbsp;&nbsp;&nbsp;&nbsp;<a href="#op_email_address_harvesting_attack">7.3.</a>&nbsp;
OpenID Provider Email-Address Harvesting Attack<br />
&nbsp;&nbsp;&nbsp;&nbsp;<a href="#uri_security_considerations">7.4.</a>&nbsp;
URI Security Considerations<br />
<a href="#anchor8">8.</a>&nbsp;
Acknowledgements<br />
<a href="#anchor9">Appendix&nbsp;A.</a>&nbsp;
Examples<br />
<a href="#eaut_template_example">Appendix&nbsp;A.1.</a>&nbsp;
EAUT Template Examples<br />
<a href="#XRDS_Simple_Sample">Appendix&nbsp;A.2.</a>&nbsp;
XRDS Service Element Examples<br />
<a href="#eaut_template_sample_1">Appendix&nbsp;A.2.1.</a>&nbsp;
EAUT Template Service Element Example 1<br />
<a href="#eaut_template_sample_2">Appendix&nbsp;A.2.2.</a>&nbsp;
EAUT Template Service Element Example 2<br />
<a href="#eaut_template_sample_3">Appendix&nbsp;A.2.3.</a>&nbsp;
EAUT Template Service Element Example 3<br />
<a href="#eaut_mapping_sample_1">Appendix&nbsp;A.3.</a>&nbsp;
EAUT Mapping Service Element Example 1<br />
<a href="#eaut_mapping_query_example">Appendix&nbsp;A.4.</a>&nbsp;
EAUT Mapping Service HTTP Example<br />
<a href="#rfc.references1">9.</a>&nbsp;
Normative References<br />
<a href="#rfc.authors">&#167;</a>&nbsp;
Authors' Addresses<br />
</p>
<br clear="all" />

<a name="anchor1"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td></tr></table>
<a name="rfc.section.1"></a><h3>1.&nbsp;
Requirements Notation</h3>

<p>
				The key words "MUST", "MUST NOT", "REQUIRED", "SHALL",
				"SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED",
				"MAY", and "OPTIONAL" in this document are to be
				interpreted as described in
				<a class='info' href='#RFC2119'>[RFC2119]<span> (</span><span class='info'>Bradner, S., &ldquo;Key words for use in RFCs to Indicate 						Requirement Levels,&rdquo; .</span><span>)</span></a>
				.
			
</p>
<a name="terminology"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td></tr></table>
<a name="rfc.section.2"></a><h3>2.&nbsp;
Terminology</h3>

<p>
				</p>
<blockquote class="text"><dl>
<dt>Email Identifier:</dt>
<dd>
						An RFC2822 "addr-spec" compatible email address
						that can be used in the Email Address to URL
						Transformation protocol. This address consists
						of a "local-part" and a "domain" part, separated
						by an "@" sign.
					
</dd>
<dt>Processing-Agent</dt>
<dd>
						An agent (e.g, a computer program) attempting to
						perform an Email Identifier to URL Transform
						operation.
					
</dd>
<dt>URI Result</dt>
<dd>
						A URI (commonly referred to as a "URL" within
						this document) that is the result of this
						protocol.
					
</dd>
<dt>Discovery Endpoint URL:</dt>
<dd>
						A URL that can be dereferenced to obtain an
						XRDS-Simple document listing the supported
						transformation mechanisms for a particular Email
						Identifier. This URL is formed by taking the
						"domain" portion of a Email Identifier, and
						following the steps outlined in
						<a class='info' href='#obtaining-discovery-endpoint'>Determining the EAUT Discovery Endpoint URL<span> (</span><span class='info'>Determining the EAUT Discovery Endpoint URL</span><span>)</span></a>
						.
					
</dd>
<dt>Email Address To URL Tranformation Mapping Service (EAUT Mapping Service)</dt>
<dd>
						A web-based service that accepts a particular
						Email Identifier, and returns a 302 redirect to
						a URL.
					
</dd>
<dt>EAUT Mapping Service Endpoint URL</dt>
<dd>
						A URL where a particular EAUT Mapping Service
						can be accessed.
					
</dd>
<dt>Email Address to URL Transformation Template (EAUT Template)</dt>
<dd>
						A URI, containing zero or more Wildcard
						Replacement Tokens.
					
</dd>
<dt>Wildcard Replacement Token</dt>
<dd>
						A string surrounded by an opening-brace and a
						closing-brace, in that order (such as
						{username}). The Wildcard Replacement Token is
						used inside of an EAUT Template to designate how
						associated URLs are structured.
					
</dd>
</dl></blockquote><p>
			
</p>
<a name="anchor2"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td></tr></table>
<a name="rfc.section.3"></a><h3>3.&nbsp;
Protocol Overview </h3>

<p>
				</p>
<ol class="text">
<li>
						An Email Identifier is presented to the
						Processing-Agent.
					
</li>
<li>
						The Processing-Agent performs
						<a class='info' href='#discovery'>discovery<span> (</span><span class='info'>EAUT Discovery</span><span>)</span></a>
						on the Email Identifier and retrieves an
						XRDS-Simple document containing one or more
						values representing an EAUT Template and/or an
						EAUT Mapping Service Endpoint URL.
					
</li>
<li>
						(Optional) If an EAUT Template is found, it can
						be used to
						<a class='info' href='#eaut_template_transformation'>transform<span> (</span><span class='info'>Transforming an Email Address using an EAUT Template</span><span>)</span></a>
						the Email Identifier into an URL.
					
</li>
<li>
						(Optional) If an EAUT Mapping Service Endpoint
						is found, it can be used to query the EAUT
						Mapping Service to determine the URL associated
						with the supplied Email Identifier.
					
</li>
<li>
						The resulting URL can then be used as an
						equivalent identifier for the Email Identifier
						in URL-based transactions.
					
</li>
</ol><p>
			
</p>
<a name="discovery"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td></tr></table>
<a name="rfc.section.4"></a><h3>4.&nbsp;
EAUT Discovery</h3>

<p>
				EAUT Discovery is the process by which a Processing
				Agent utilizes a Discovery Endpoint URL to look up
				("discover") the information necessary for transforming
				an Email Identifier into an URL. This protocol has only
				one path through which to do discovery:
			
</p>
<p>
				</p>
<ol class="text">
<li>
						<a class='info' href='#XRDS-Simple'>XRDS-Simple<span> (</span><span class='info'>Hammer-Lahav, E., &ldquo;XRDS-Simple 1.0,&rdquo; .</span><span>)</span></a> [XRDS&#8209;Simple]
						Document Retreival SHALL performed on the EAUT
						Discovery Endpoint URL. If this process
						succeeds, the result is an XRDS-Simple document
						that contains the necessary information for the
						protocol to continue. If more than one
						applicable Service Element is returned in the
						XRDS-Simple document, the precedence rules
						defined in [XRDS-Simple] are to be applied.
					
</li>
</ol><p>
			
</p>
<p>
				If the XRDS-Simple protocol fails for any reason (e.g.,
				no valid XRDS-Simple document is retrieved, or no valid
				<a class='info' href='#valid_service_type_elements'>Service Elements<span> (</span><span class='info'>Valid Service Type Elements</span><span>)</span></a>
				are found in the XRDS-Simple document), then discovery
				is considered to have failed for the supplied EAUT
				Discovery Endpoint URL.
			
</p>
<a name="obtaining-discovery-endpoint"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td></tr></table>
<a name="rfc.section.4.1"></a><h3>4.1.&nbsp;
Determining the EAUT Discovery Endpoint URL</h3>

<p>
					In order to obtain a Discovery Endpoint URL from an
					Email Identifier, the following process MUST be
					followed:
				
</p>
<p>
					</p>
<ol class="text">
<li>
							Parse the Email Identifier using the "at
							sign" ("@" ASCII #40) as a delimiter. The
							result of this parsing operation SHOULD be
							two tokens, the second of which will be the
							"domain" of the Email Identifier as defined
							by RFC2822, section 3.4.1. (The first token
							will be the "local-part" as defined by
							RFC2822). The first token SHOULD be
							discarded, leaving the second token, which
							is the "domain".
							<br />
<br />

						
</li>
<li>
							Using the "domain" result from the first
							step, prepend the string "http://" to it.
							<br />
<br />

						
</li>
<li>
							The resulting URL is a valid EAUT Discovery
							Endpoint URL, and can be used to perform
							EAUT Discovery.
							<br />
<br />

						
</li>
<li>
							If EAUT Discovery is not successful on the
							EAUT Discovery Endpoint URL obtained in the
							step above (i.e., no XRDS-Simple document is
							found, or no valid Service Elements are
							found in the XRDS-Simple document), then a
							new URL should be assembled by starting with
							the "domain" result from the first step, and
							prepending the string "http://www." to it.
							<br />
<br />

						
</li>
<li>
							The resulting URL is a valid EAUT Discovery
							Endpoint URL and can be used to perform EAUT
							Discovery. If EAUT Discovery is again
							unsuccessful on this final Endpoint URL,
							then Email Address Transformation is not
							possible with the supplied Email Identifier.
							The Processing Agent SHOULD treat the
							supplied Email Identifier as it would any
							other invalid user-supplied identifier.
						
</li>
</ol><p>
				
</p>
<a name="discovered_info"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td></tr></table>
<a name="rfc.section.4.2"></a><h3>4.2.&nbsp;
Discovered Information</h3>

<p>
					Upon successful completion of EAUT Discovery, the
					Processing Agent will have an XRDS-Simple document
					containing the EAUT Protocol version, as well as one
					or more of the following pieces of information:

					</p>
<ul class="text">
<li>EAUT Template
</li>
<li>EAUT Mapping Service Endpoint URL
</li>
</ul><p>
				
</p>
<a name="anchor3"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td></tr></table>
<a name="rfc.section.4.3"></a><h3>4.3.&nbsp;
XRDS-Based Discovery</h3>

<p>
					If XRDS-Simple discovery was successful, the result
					will be an XRDS-Simple Document, which is defined in
					[XRDS-Simple]. This is an XML document with entries
					for services that are related to the Email
					Identifier.
				
</p>
<a name="valid_service_type_elements"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td></tr></table>
<a name="rfc.section.4.3.1"></a><h3>4.3.1.&nbsp;
Valid Service Type Elements</h3>

<p>
						For non-normative examples of XRDS-Simple
						Service Elements supported by this protocol, see
						the
						<a class='info' href='#XRDS_Simple_Sample'>XRDS Examples<span> (</span><span class='info'>XRDS Service Element Examples</span><span>)</span></a>
						section.
					
</p>
<a name="anchor4"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td></tr></table>
<a name="rfc.section.4.3.1.1"></a><h3>4.3.1.1.&nbsp;
Service Type: EAUT Template</h3>

<p>
							An EAUT Template element is an
							&lt;xrd:Service&gt; element with the
							following information:

							</p>
<ul class="text">
<li>
									An &lt;xrd:Type&gt; tag whose text
									content is
									"http://specs.eaut.org/1.0/template".
								
</li>
<li>
									An &lt;xrd:URI&gt; tag whose text
									content is an EAUT Template.
								
</li>
</ul><p>
						
</p>
<a name="anchor5"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td></tr></table>
<a name="rfc.section.4.3.1.2"></a><h3>4.3.1.2.&nbsp;
Service Type: EAUT Mapping Service</h3>

<p>
							An EAUT Mapping Service element is an
							&lt;xrd:Service&gt; element with the
							following information:

							</p>
<ul class="text">
<li>
									An &lt;xrd:Type&gt; tag whose text
									content is
									"http://specs.eaut.org/1.0/mapping".
								
</li>
<li>
									An &lt;xrd:URI&gt; tag whose text
									content is an an EAUT Mapping
									Service Endpoint URL.
								
</li>
</ul><p>
						
</p>
<a name="extracting_auth"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td></tr></table>
<a name="rfc.section.4.3.2"></a><h3>4.3.2.&nbsp;
Extracting the EAUT Template or EAUT Mapping Service Endpoint URL</h3>

<p>
						Once the Processing Agent has obtained an XRDS
						document, it MUST first search the document
						(following the rules described in [XRDS-Simple])
						for either an EAUT Template or an EAUT Mapping
						Service Endpoint URL. If neither of these are
						found, then the EAUT protocol fails.
					
</p>
<a name="eaut_template_transformation"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td></tr></table>
<a name="rfc.section.5"></a><h3>5.&nbsp;
Transforming an Email Address using an EAUT Template</h3>

<p>
				In order to transform a Email Identifier into an URL, a
				Processing Agent may utilize a valid EAUT Template. This
				section details the structure of the EAUT Template, as
				well as the steps necessary to transform an Email
				Address into an URL using an EAUT Template.
			
</p>
<a name="eaut_template_structure"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td></tr></table>
<a name="rfc.section.5.1"></a><h3>5.1.&nbsp;
EAUT Template Structure</h3>

<p>
					An EAUT Template is an absolute URI that contains
					zero or more Wildcard Replacement Fields, each of
					which are textual character(s) surrounded by an
					opening-brace ("{" ASCII #7B ) on the left, and a
					closing-brace ("}" ASCII #7D) on the right.
					<br />
<br />

					As of this version of the Transform protocol, the
					only allowed replacement field is "username".
					<br />
<br />

					Because the "opening-bracket" and "closing-bracket"
					characters are prohibited by the URI syntax, these
					characters MUST be percent-encoded per section 2.1
					of the URI Specification before being included in an
					XRDS document.
				
</p>
<a name="eaut_template_validity"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td></tr></table>
<a name="rfc.section.5.2"></a><h3>5.2.&nbsp;
EAUT Template Validity</h3>

<a name="valid_eaut_template"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td></tr></table>
<a name="rfc.section.5.2.1"></a><h3>5.2.1.&nbsp;
Valid EAUT Template</h3>

<p>
						An EAUT Template is considered to be valid if it
						is either a valid URL, or a URL with a Wildcard
						Replacement Field as allowed by this protocol.
						Currently, only the {username} Wildcard
						Replacement Field is defined and allowed.
					
</p>
<a name="invalid_eaut_template"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td></tr></table>
<a name="rfc.section.5.2.2"></a><h3>5.2.2.&nbsp;
Invalid EAUT Template</h3>

<p>
						An EAUT Template is considered to be invalid if
						the EAUT Template has any of the following
						properties:
						</p>
<ul class="text">
<li>
								It contains more than one of either kind
								of bracket.
							
</li>
<li>
								It contains an odd number of brackets.
							
</li>
</ul><p>

						An invalid EAUT Template MUST NOT be used in an
						Email Identifier Transform operation.
					
</p>
<a name="eaut_template_transform_procedure"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td></tr></table>
<a name="rfc.section.5.3"></a><h3>5.3.&nbsp;
EAUT Template Transform Procedure</h3>

<p>
					If the valid EAUT Template does not contain any
					Wildcard Replacement Fields, then the transform is
					complete: The EAUT Template is the URL, and this
					transform protocol ends.
					<br />
<br />

					However, if the EAUT Template does contain a
					Wildcard Replacement Field, then the following
					procedure is used to transform the Email Identifier
					into an URL using an EAUT Template:
				
</p>
<p>
					</p>
<ol class="text">
<li>
							Tokenize the Email Identifier using the "at
							sign" ("@" ASCII #40) as a delimeter. The
							result of this parsing operation SHOULD be
							two tokens, the first of which will be the
							"local-part" of the Email Identifier as
							defined by RFC2822, section 3.4.1. (The
							second token will be the "domain").
							<br />
<br />

						
</li>
<li>
							The EAUT Template should be percent-decoded
							per section 2.1 of the URI specification.
							Specifically, %5B should be decoded to be
							the opening-bracket, while %5D should be
							decoded to be the closing bracket, but only
							where these two characters surround a valid
							Wildcard Replacement String (such as
							"username").
							<br />
<br />

						
</li>
<li>
							Next, in the EAUT Template replace the
							portion of the EAUT Template that contains
							"{username}" (excluding double-quotes) with
							the value of the "local-part" portion of the
							Email Identifier.
							<br />
<br />

						
</li>
</ol><p>
				
</p>
<a name="eaut_mapping_transformation"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td></tr></table>
<a name="rfc.section.6"></a><h3>6.&nbsp;
Transforming an Email Identifier using an EAUT Mapping Service</h3>

<p>
				In order to transform a Email Identifier into an URL,
				Processing Agents may utilize an EAUT Mapping Service.
				This section details how Processing Agents can access
				such service endpoints, and the expected results that
				MUST be returned.
			
</p>
<a name="eaut_mapping_service_query"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td></tr></table>
<a name="rfc.section.6.1"></a><h3>6.1.&nbsp;
EAUT Mapping Service Query</h3>

<p>
					In order to query an EAUT Mapping Service, a
					Processing Agent SHOULD issue an HTTP GET request on
					the EAUT Mapping Service's Endpoint URL. The GET
					request must contain an attribute named "email",
					with the Email Identifier as the value of this
					attribute. If more than one "email" attribute is
					specified in the GET query, then EAUT Mapping
					Service Endpoints SHOULD utilize only the first
					attribute in the query string. See Appendix A.4 for
					a non-normative example of an EAUT Mapping Service
					Query.
				
</p>
<a name="eaut_mapping_service_result"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td></tr></table>
<a name="rfc.section.6.2"></a><h3>6.2.&nbsp;
EAUT Mapping Service Result</h3>

<p>
					After receiving an EAUT Mapping Service Query, an
					EAUT Mapping Service MAY return one of the following
					HTTP status codes:
				
</p>
<p>
					</p>
<blockquote class="text"><dl>
<dt>HTTP 302 (Redirect)</dt>
<dd>
							An HTTP 302 redirect to an appropriately
							mapped URL.
						
</dd>
<dt>HTTP 400 (Bad Request)</dt>
<dd>
							An HTTP 400 (Bad Request) if the supplied
							Email Identifier is not properly formatted
							per this spec and RFC2822.
						
</dd>
<dt>HTTP 500 (Internal Server Error)</dt>
<dd>
							An HTTP 500 (Internal Server Error) if the
							Mapping Service encounters an internal or
							processing error.
						
</dd>
</dl></blockquote><p>
				
</p>
<p>
					Assuming a Processing Agent is utilizing the correct
					Mapping Service Endpoint URL, the Mapping Service
					should never return a 404 (Not Found) result after
					encountering a transform request for a properly
					formatted, but non-existent email address. Only a
					302 (redirect) should be returned in this case. See
					the Security Considerations for more details.
				
</p>
<a name="anchor6"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td></tr></table>
<a name="rfc.section.7"></a><h3>7.&nbsp;
Security Considerations</h3>

<a name="anchor7"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td></tr></table>
<a name="rfc.section.7.1"></a><h3>7.1.&nbsp;
Man-in-the-Middle Attacks</h3>

<p>
					If DNS resolution or the transport layer is
					compromised, this protocol is not fully secure since
					the attacker can impersonate the Discovery Endpoing
					URL and tamper with the discovery process. If an
					attacker can tamper with the discovery process
					he/she can specify any URL, and so does not have to
					impersonate the mapped URL. Additionally, if an
					attacker can compromise the integrity of the
					information returned during the discovery process,
					by altering the XRDS document, the need for a man in
					the middle is removed. In such an attack, a forged
					EAUT Template or forged EAUT Mapping Service
					Endpoint URL could be returned. One method to
					prevent this sort of attack is by digitally signing
					the XRDS file as per
					<a class='info' href='#RFC3275'>XMLDSIG<span> (</span><span class='info'>Eastlake 3rd, D., Reagle Jr., J., and D. Solo, &ldquo;(Extensible Markup Language) XML-Signature 						Syntax and Processing,&rdquo; .</span><span>)</span></a> [RFC3275]
					. The keying material is not specified, since the
					Processing Agent ultimately needs to make its own
					decision whether to trust keys used for such a
					signature.
				
</p>
<p>
					Using SSL with certificates signed by a trusted
					authority prevents these kinds of attacks by
					verifying the results of the DNS look-up against the
					certificate. Once the validity of the certificate
					has been established, tampering is not possible.
					Impersonating an SSL server requires forging or
					stealing a certificate, which is significantly
					harder than the network based attacks.
				
</p>
<p>
					In order to get protection from SSL, SSL must be
					used for all parts of this protocol, While the
					protocol does not require SSL be used, its use is
					strongly RECOMMENDED. Current best practices dictate
					that Discovery Endpoint URL SHOULD use SSL, with a
					certificate signed by a trusted authority, to secure
					its Endpoint URL as well as the interactions with
					the Processing Agent. Following its own security
					policies, a Processing Agent MAY choose to not
					complete, or even begin, a transaction if SSL is not
					being correctly used at the Discovery Endpoint URL.
				
</p>
<a name="eaut_mapping_service_email_address_harvesting_attack"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td></tr></table>
<a name="rfc.section.7.2"></a><h3>7.2.&nbsp;
EAUT Mapping Email-Address Harvesting Attack</h3>

<p>
					EAUT Mapping Service Endpoints may be prone to an
					email address harvesting attack if the EAUT Mapping
					Service returns different HTTP codes for different
					email addresses. For example, if an EAUT Mapping
					Service determines that a particular Email
					Identifier is not actually in use, and then returns
					a special result message to indicate this, an
					attacker could utilize this information in order to
					determine if a particular Email Identifier is valid
					or not for a particular domain.

					Thus, in order to reduce the risk of email address
					harvesting attacks, an EAUT Mapping Service should
					always redirect to a well-formed URL, even if the
					system is unable to verify that supplied email
					address actually corresponds to a valid user. In
					this way, an attacker will not be able to determine
					if a particular Email Identifier is actually
					registered with the EAUT Mapping Service.
				
</p>
<a name="op_email_address_harvesting_attack"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td></tr></table>
<a name="rfc.section.7.3"></a><h3>7.3.&nbsp;
OpenID Provider Email-Address Harvesting Attack</h3>

<p>
					OpenID Providers (OP's) should be careful to always
					resolve a particular OpenID URL, even if that OpenID
					URL is not a valid OpenID in the OP system. If a
					particular OP does not resolve *all* OpenID
					Identifier URL's, then an email address harvesting
					attack could utilize an EAUT Service Endpoint to
					determine which email addresses correspond to valid
					OpenID Identifiers, thus increasing the value of
					harvested email addresses. This recomendation holds
					true outside of this specification, although it is
					highlighted here because EAUT can exacerbate this
					problem by possibly connecting an Email Identifier
					to a particular OpenID Identifier.
				
</p>
<a name="uri_security_considerations"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td></tr></table>
<a name="rfc.section.7.4"></a><h3>7.4.&nbsp;
URI Security Considerations</h3>

<p>
					An EAUT Template does not contain active or
					executable content. However, other security
					considerations are the same as those for URIs. See
					RFC3986, section 7 for more details.
				
</p>
<a name="anchor8"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td></tr></table>
<a name="rfc.section.8"></a><h3>8.&nbsp;
Acknowledgements</h3>

<p>
				Textual portions of this document were modeled on or
				inspired by OpenID Authentication 2.0 and
				<a class='info' href='#draft-gregorio-uritemplate-03'>URI Template<span> (</span><span class='info'>Gregorio, J., Ed., Hadley, M., Ed., Nottingham, M., Ed., and D. Orchard, &ldquo;URI Template,&rdquo; .</span><span>)</span></a> [draft&#8209;gregorio&#8209;uritemplate&#8209;03]
				. XML portions of the OpenID Attribute Exchange 1.0
				specifications were also used in the creation of this
				document.
			
</p>
<a name="anchor9"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td></tr></table>
<a name="rfc.section.A"></a><h3>Appendix A.&nbsp;
Examples</h3>

<p>Non-normative
</p>
<a name="eaut_template_example"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td></tr></table>
<a name="rfc.section.A.1"></a><h3>Appendix A.1.&nbsp;
EAUT Template Examples</h3>
<div style='display: table; width: 0; margin-left: 3em; margin-right: auto'><pre>https://{username}.example.com/</pre></div><div style='display: table; width: 0; margin-left: 3em; margin-right: auto'><pre>https://www.example.com/server/{username}</pre></div>
<a name="XRDS_Simple_Sample"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td></tr></table>
<a name="rfc.section.A.2"></a><h3>Appendix A.2.&nbsp;
XRDS Service Element Examples</h3>

<a name="eaut_template_sample_1"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td></tr></table>
<a name="rfc.section.A.2.1"></a><h3>Appendix A.2.1.&nbsp;
EAUT Template Service Element Example 1</h3>

<p>
							For an Email Identifier "beth@example.com"
							to transform to the URL
							"https://beth.example.com", the following
							XML snippet should be present in the the
							XRDS file when discovery is performed on
							"https://example.com/" or
							"https://www.example.com":
						
</p><div style='display: table; width: 0; margin-left: 3em; margin-right: auto'><pre>

&lt;Service xmlns="xri://$xrd*($v*2.0)"&gt;
  &lt;Type&gt;http://specs.eaut.org/1.0/template&lt;/Type&gt;
  &lt;URI&gt;https://%5Busername%5D.example.com/&lt;/URI&gt;
&lt;/Service&gt;

</pre></div>
<a name="eaut_template_sample_2"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td></tr></table>
<a name="rfc.section.A.2.2"></a><h3>Appendix A.2.2.&nbsp;
EAUT Template Service Element Example 2</h3>

<p>
							For an Email Identifier "beth@example.com"
							to transform to the URL
							"https://www.example.com/openid/personas/beth",
							the following XML snippet should be present
							in the the XRDS file when discovery is
							performed on "https://example.com/" or
							"https://www.example.com":
						
</p><div style='display: table; width: 0; margin-left: 3em; margin-right: auto'><pre>

&lt;Service xmlns="xri://$xrd*($v*2.0)"&gt;
  &lt;Type&gt;http://specs.eaut.org/1.0/template&lt;/Type&gt;
  &lt;URI&gt;https://www.example.com/openid/personas/%5Busername%5D/&lt;/URI&gt;
&lt;/Service&gt;

</pre></div>
<a name="eaut_template_sample_3"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td></tr></table>
<a name="rfc.section.A.2.3"></a><h3>Appendix A.2.3.&nbsp;
EAUT Template Service Element Example 3</h3>

<p>
							For all Email Identifiers "*@example.com" to
							use the URL "https://www.example.com/", the
							following XML snippet should be present in
							the the XRDS file when discovery is
							performed on "https://example.com/" or
							"https://www.example.com":
						
</p><div style='display: table; width: 0; margin-left: 3em; margin-right: auto'><pre>

&lt;Service xmlns="xri://$xrd*($v*2.0)"&gt;
  &lt;Type&gt;http://specs.eaut.org/1.0/template&lt;/Type&gt;
  &lt;URI&gt;https://www.example.com/&lt;/URI&gt;
&lt;/Service&gt;

</pre></div>
<a name="eaut_mapping_sample_1"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td></tr></table>
<a name="rfc.section.A.3"></a><h3>Appendix A.3.&nbsp;
EAUT Mapping Service Element Example 1</h3>

<p>
						For an Email Identifier "beth@example.com" to
						transform to the URL
						"https://www.example.com/openid/personas/beth",
						using an EAUT Mapping Service, the following XML
						snippet should be present in the the XRDS file
						when discovery is performed on
						"https://example.com/" or
						"https://www.example.com":
					
</p><div style='display: table; width: 0; margin-left: 3em; margin-right: auto'><pre>

&lt;Service xmlns="xri://$xrd*($v*2.0)"&gt;
  &lt;Type&gt;http://specs.eaut.org/1.0/mapping&lt;/Type&gt;
  &lt;URI&gt;https://example.com/eaut_mapping/&lt;/URI&gt;
&lt;/Service&gt;

</pre></div>
<a name="eaut_mapping_query_example"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td></tr></table>
<a name="rfc.section.A.4"></a><h3>Appendix A.4.&nbsp;
EAUT Mapping Service HTTP Example</h3>

<p>
						The following is an example HTTP GET request
						that could be made to an EAUT Mapping Service
						Endpoint URL to determine the URL for an Email
						Address of "beth@example.com".
					
</p><div style='display: table; width: 0; margin-left: 3em; margin-right: auto'><pre>

GET /eaut_mapping/?email%3Dbeth@example.com HTTP/1.1
Date: Wed, 08 Jun 2008 04:06:18 GMT
Host: example.com

</pre></div>
<p>
						The following is an example response containing
						a 302 redirect code for the above reqest:
					
</p><div style='display: table; width: 0; margin-left: 3em; margin-right: auto'><pre>

HTTP/1.1 302 Found
Location: http://openid.example.com/people/beth

</pre></div>
<a name="rfc.references1"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td></tr></table>
<h3>9.&nbsp;Normative References</h3>
<table width="99%" border="0">
<tr><td class="author-text" valign="top"><a name="ASCII">[ASCII]</a></td>
<td class="author-text">The Unicode Consortium, &ldquo;<a href="http://www.unicode.org/charts/PDF/U0000.pdf">The ASCII subset of the Unicode Standard 5.0</a>.&rdquo;</td></tr>
<tr><td class="author-text" valign="top"><a name="OpenID.authentication-2.0">[OpenID.authentication-2.0]</a></td>
<td class="author-text"><a href="mailto:specs@openid.net">OpenID Foundation</a>, &ldquo;OpenID Authentication 2.0 - Final,&rdquo; December&nbsp;2007 (<a href="http://openid.net/specs/openid-authentication-2_0.txt">TXT</a>, <a href="http://openid.net/specs/openid-authentication-2_0.html">HTML</a>).</td></tr>
<tr><td class="author-text" valign="top"><a name="RFC2119">[RFC2119]</a></td>
<td class="author-text">Bradner, S., &ldquo;<a href="http://tools.ietf.org/html/rfc2119">Key words for use in RFCs to Indicate
						Requirement Levels</a>,&rdquo; RFC&nbsp;2119.</td></tr>
<tr><td class="author-text" valign="top"><a name="RFC2616">[RFC2616]</a></td>
<td class="author-text">Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, &ldquo;<a href="http://tools.ietf.org/html/rfc2616">Hypertext Transfer Protocol -- HTTP/1.1</a>,&rdquo; RFC&nbsp;2616.</td></tr>
<tr><td class="author-text" valign="top"><a name="RFC2822">[RFC2822]</a></td>
<td class="author-text">Resnick, P., &ldquo;<a href="http://tools.ietf.org/html/rfc2822">Internet Message Format</a>,&rdquo; RFC&nbsp;2822.</td></tr>
<tr><td class="author-text" valign="top"><a name="RFC3275">[RFC3275]</a></td>
<td class="author-text">Eastlake 3rd, D., Reagle Jr., J., and D. Solo, &ldquo;<a href="http://tools.ietf.org/html/rfc3275">(Extensible Markup Language) XML-Signature
						Syntax and Processing</a>,&rdquo; RFC&nbsp;3275.</td></tr>
<tr><td class="author-text" valign="top"><a name="RFC3986">[RFC3986]</a></td>
<td class="author-text">Berners-Lee, T., Fielding, R., and L. Masinter, &ldquo;<a href="http://tools.ietf.org/html/rfc3986">Uniform Resource Identifier (URI): Generic
						Syntax</a>,&rdquo; RFC&nbsp;3986.</td></tr>
<tr><td class="author-text" valign="top"><a name="XRDS-Simple">[XRDS-Simple]</a></td>
<td class="author-text">Hammer-Lahav, E., &ldquo;<a href="http://xrds-simple.net/core/1.0/">XRDS-Simple 1.0</a>.&rdquo;</td></tr>
<tr><td class="author-text" valign="top"><a name="draft-gregorio-uritemplate-03">[draft-gregorio-uritemplate-03]</a></td>
<td class="author-text"><a href="mailto:joe@bitworking.org">Gregorio, J., Ed.</a>, <a href="mailto:Marc.Hadley@sun.com">Hadley, M., Ed.</a>, <a href="mailto:mnot@pobox.com">Nottingham, M., Ed.</a>, and <a href="mailto:dorchard@bea.com">D. Orchard</a>, &ldquo;<a href="http://xrds-simple.net/core/1.0/">URI Template</a>.&rdquo;</td></tr>
</table>

<a name="rfc.authors"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td></tr></table>
<h3>Authors' Addresses</h3>
<table width="99%" border="0" cellpadding="0" cellspacing="0">
<tr><td class="author-text">&nbsp;</td>
<td class="author-text">David Fuelling</td></tr>
<tr><td class="author-text">&nbsp;</td>
<td class="author-text">Sappenin Technologies LLC</td></tr>
<tr><td class="author-text">&nbsp;</td>
<td class="author-text">Salt Lake City, UT  84117</td></tr>
<tr><td class="author-text">&nbsp;</td>
<td class="author-text">USA</td></tr>
<tr><td class="author" align="right">Email:&nbsp;</td>
<td class="author-text"><a href="mailto:sappenin@gmail.com">sappenin@gmail.com</a></td></tr>
<tr><td class="author" align="right">URI:&nbsp;</td>
<td class="author-text"><a href="http://www.sappenin.com">http://www.sappenin.com</a></td></tr>
<tr cellpadding="3"><td>&nbsp;</td><td>&nbsp;</td></tr>
<tr><td class="author-text">&nbsp;</td>
<td class="author-text">Will Norris</td></tr>
<tr><td class="author-text">&nbsp;</td>
<td class="author-text">Vidoop, LLC</td></tr>
<tr><td class="author-text">&nbsp;</td>
<td class="author-text">Tulsa, OK  74119</td></tr>
<tr><td class="author-text">&nbsp;</td>
<td class="author-text">USA</td></tr>
<tr><td class="author" align="right">Email:&nbsp;</td>
<td class="author-text"><a href="mailto:will@willnorris.com">will@willnorris.com</a></td></tr>
<tr><td class="author" align="right">URI:&nbsp;</td>
<td class="author-text"><a href="http://willnorris.com/">http://willnorris.com/</a></td></tr>
</table>
</body></html>

